1) Technical Field
This invention relates to using a hardware description language (HDL) such as Verilog or VHDL in conjunction with a conventional programming language such as C, C++ or for performing the logical simulation of digital electronic systems.
2) Discussion of the Prior Art
Hardware design or verification engineers modeling a complex digital system often find that different modeling languages have both strengths and weaknesses in implementing the desired model. For example, an HDL, such as Verilog, may be well suited for describing specific hardware structures and behaviors, while a conventional programming language, such as C, would complement the HDL by providing more abstract system-related functions and algorithms. Consequently, it is often desirable to integrate an HDL and a conventional programming language in order to model a complex digital system.
At the same time, the fact that two very different languages are used together for modeling means that any inherent differences between the two modeling languages must be accommodated. One of the differences between an HDL and a programming language is that the concept of simulated time is built into the HDL, while simulated time is not provided in a conventional programming language. The logical HDL simulation takes a number of time steps, while the conventional programming language does not. Partial accommodation of these differences and communication between these languages is most commonly provided by a Programming Language Interface (PLI).
The Institute of Electrical and Electronic Engineers (IEEE) standard 1364 defines both the PLI and the Verilog HDL. The PLI, illustrated in FIG. 1, provides table-based mapping of function names between Verilog and C, and a set of simulator routines that can be called from C to read and write the arguments. The PLI interface code, the PLI access library and the indirection lookup table provide indirect links between the user application programming language code and the HDL simulator. Such PLI programming is complex, difficult to learn, and inappropriate for simple applications. VHDL has a similar kind of interface called the Foreign Language Interface (FLI). Hereafter, the acronym PLI will be used to include both the PLI and the FLI language interfaces.
Many programming language considerations are involved in forming a combination of an HDL and a conventional programming language. Programming languages and HDLs can be compiled or interpreted. A compiler converts language source code into object code for a particular machine. This is often used for languages like C++. An interpreter converts language source code into its own data format, which is then executed. This is often used for languages like PERL. An HDL simulator can use either technique or both, and may use special-purpose hardware to accelerate the simulation. Accordingly, an environment that uses combinations of such languages must provide for compiled, interpreted or accelerated versions on either side of the modeling interface.
Another consideration is that object code can be made ‘shared’ so that one or more programs can link to it while running. The linking applies to both routine calls and variables. The PLI does not provide direct sharing of user-defined variables, but only via routines to access the names used in calls from the HDL, as illustrated in FIG. 2.
HDLs distinguish between HDL functions and Verilog tasks or VHDL procedures. The Verilog term ‘task’ is used in this document hereafter to include the very similar VHDL term ‘procedure.’ HDL functions cannot have a simulation time duration, while Verilog tasks can have timing and event controls and so take simulation time. In either Verilog or VHDL, expressions can be function calls, but expressions cannot be task calls.
The Verilog PLI currently requires calls and returns to be in the same simulator time step, thus requiring that all C code routines execute in one time step. Furthermore, in the current Verilog PLI, the arguments must be accessed from the programming language by routine calls, as illustrated in FIG. 3.
For a complete model of C software controlling hardware, such as in an embedded system simulation, the C control code must be able to interact with a Verilog simulation of the hardware so that the control code can make a call to an HDL task during a simulator time step, and the call does not return to the control code until one or more simulator time steps later. This is not supported in the IEEE 1364 standard. One approach is to keep the C control code and the Verilog simulation as different programs, communicating by Unix facility known as a ‘socket’. Some users have implemented socket interfaces to provide this functionality, even for testbench applications. This is even slower and more complex than using the PLI, and its use has been primarily in so-called “co-verification” products.
To allow concurrency in general programming languages, there are ‘threads’ packages available in the public domain. Each ‘thread’ represents a sequence that can run concurrently with other threads. In practice each thread executes part of its sequence, then waits for another thread to execute, and so on. Each wait involves saving the stack, so it can be restored later. These thread packages are hard to learn and use.
There remains, therefore, a need for a simulator that makes the interface between HDLs and programming languages easy to use, automatic and fast.